Engaging website visitors in a timely manner with the correct customer engagement (e.g., presenting a discount offer on a product to a website visitor who has shown interest in the product; extending an invitation to a website visitor who has shown interest in a product to chat with a sales agent about the product, etc.) has been proven to result in an increase in sales and customer satisfaction.
Determining a correct type of customer engagement to present to a website visitor visiting a website usually requires a browser running on a client device to perform following steps:                1) On every page, make a request to an engagement server. Optionally, this can be done through a JavaScript/Flash request with additional data related to the page or the browser.        2) Poll the engagement server for next action. Optionally, a socket connection can be established and left open during an engagement.        3) The engagement server responds with a recommended engagement to display, and the details of the engagement.        
An example of a server-based approach to customer engagement is illustrated in FIG. 1.
As shown in FIG. 1, system 100 may include a web browser application (or browser) 102, a website server 104, and an engagement server 106. For every web page requested (108), the server-based approach requires that browser 102 makes a request to engagement server 106 (110). Engagement server 106 is then periodically polled for a next action (112a-112c). Often, a socket connection between browser 102 and engagement server 106 is established (via a particular port) and left open during an engagement. In response to each poll, engagement server 106 evaluates engagement rules, determines whether to engage, and returns a response to browser 102 (114a-114c). If the response from engagement server 106 indicates a decision to engage, browser 102 then requests an engagement widget from engagement server 106 for display through browser 102 (112d).
Several problems exist with this server-based approach. For example, it is not possible for an engagement server or a decision engine at the server side to perform real-time decisioning on customer engagements. In a polling scenario such as one illustrated in FIG. 1, there will always be a time gap between polls, during which no engagement that is based on the current context of user interactions may be offered. This server-based approach therefore risks potentially missing a critical opportunity to react to context changes (due to user interactions such as mouse movements or changes in form inputs).
As another example, in the open socket connection scenario, the rate at which a decision can be processed on the server-side can be impacted by the load on the engagement server, the decision engine performance, and/or the transit time of the updated client information. These factors can all adversely impact or affect the ability of an engagement server to determine, in a timely manner, what engagement, if any, should be offered.
Furthermore, with a server-based approach, contextually-relevant information such as the location of a user's pointing device is limited to periodic updates and/or requires a stream of information travelling over network connection(s) which, again, can unfavorably impact performance. The competing interests here include the level of contextual relevance and the speed of the decisioning process on an engagement server. Typically, the need for performance (so as to avoid having to take a long time to load a page during which a website visitor may leave the page) outweighs the need for contextual relevance. Thus, an engagement server may be provided with less information that is contextually relevant to a page, a website visitor, or both. This unfortunately means that an engagement server can sometimes respond fast at the cost of accuracy and/or relevancy in determining a proper engagement, resulting in reduced or poor customer engagements.
Another issue with the server-based approach relates to network connectivity of mobile devices. Mobile devices with poor connections are extremely difficult to support using either the poll or the socket connection methods of the server-based approach described above.
Additionally, scalability can be a problematic issue, due at least in part to every page for every visitor of a website needing to either poll an engagement server or keep an open socket connection to the engagement server. Because the server requirements can be extremely high, scalability of the server-based approach is very limited, if not exceedingly cost-prohibitive.
As a result of these drawbacks, many websites take a simpler approach in which a page timer is used to trigger a decision to present an engagement. This time-based approach can also be problematic. For example, since contextual information from a page is not considered in the time-based approach, it has no impact on a website's decision to engage a website visitor who is viewing and/or interacting with the page. As such, there may not be any relationship between the website visitor's behavior on the page and the time-triggered decision to present them with an engagement. As a result, the website visitor may be bombarded with unnecessary and/or inappropriate engagement offers, leading to reduced or poor customer engagements.